Searching code based on learned programming construct patterns and NLP similarity

ABSTRACT

An approach is provided to ingest software source code files into a question/answering (QA) system. During ingestion, source code blocks are classified to identify one or more constructs in the blocks as being domain-specific. Relationships between the blocks are then mapped. Software compliance regulations are ingested into the QA system. Using the QA system, a source code file is analyzed for compliance to the software compliance regulations. The analysis identifies code sections within the source code file as being domain-specific and subject to the ingested set of software compliance regulations.

BACKGROUND

Code reuse, also called software reuse, is the use of existing software,or software knowledge, to build new software. Code reuse has been in usefrom the earliest days of programming with programmers reusing sectionsof code, templates, functions, and procedures. The goal of code reuse isto save time and resources and reduce redundancy by taking advantage ofcode that has already been created. Code reuse implies the creation of aseparately maintained version of the reusable code.

Some domains are heavily regulated for software programmers andcomplying with these regulations is difficult . Furthermore, mistakesmade that lead to non-compliance have serious financial or legalconsequences. For instance, in the medical domain the Food and DrugAdministration (FDA) requires strict documentation of all medicalalgorithms used including a full “breadcrumb”/audit trail that describesexactly what evidence source was used to create the softwarealgorithm/calculation. Thus, building a compliant solution in aregulated industry has two problems: #1 being able to find all instancesof algorithms that need to be documented and #2 verifying that proof ofdocumentation is present for each algorithm .

BRIEF SUMMARY

According to one embodiment of the present disclosure, An approach isprovided to ingest software source code files into a question/answering(QA) system. During ingestion, source code blocks are classified toidentify one or more constructs in the blocks as being domain-specific.Relationships between the blocks are then mapped. Software complianceregulations are ingested into the QA system. Using the QA system, asource code file is analyzed for compliance to the software complianceregulations. The analysis identifies code sections within the sourcecode file as being domain-specific and subject to the ingested set ofsoftware compliance regulations

The foregoing is a summary and thus contains, by necessity,simplifications, generalizations, and omissions of detail; consequently,those skilled in the art will appreciate that the summary isillustrative only and is not intended to be in any way limiting. Otheraspects, inventive features, and advantages of the present disclosure,as defined solely by the claims, will become apparent in thenon-limiting detailed description set forth below.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The present disclosure may be better understood, and its numerousobjects, features, and advantages made apparent to those skilled in theart by referencing the accompanying drawings, wherein:

FIG. 1 depicts a schematic diagram of one illustrative embodiment of aquestion/answer creation (QA) system in a computer network;

FIG. 2 illustrates an information handling system, more particularly, aprocessor and common components, which is a simplified example of acomputer system capable of performing the computing operations describedherein;

FIG. 3 is an exemplary diagram showing processes and data storesutilized to search software source code based on learned programmingconstruct patterns and natural language processing (NLP) similarities;

FIG. 4 is an exemplary flowchart showing steps performed to build adomain specific base of source code knowledge;

FIG. 5 is an exemplary flowchart that performs steps to comply withvarious regulations related to software that is being constructed; and

FIG. 6 is an exemplary flowchart that processes formulated questionspertaining to code using a question/answering (QA) system.

DETAILED DESCRIPTION

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the disclosure.As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present disclosure has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the disclosure in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the disclosure. Theembodiment was chosen and described in order to best explain theprinciples of the disclosure and the practical application, and toenable others of ordinary skill in the art to understand the disclosurefor various embodiments with various modifications as are suited to theparticular use contemplated.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions. The following detailed description willgenerally follow the summary of the disclosure, as set forth above,further explaining and expanding the definitions of the various aspectsand embodiments of the disclosure as necessary.

FIG. 1 depicts a schematic diagram of one illustrative embodiment of aquestion/answer (QA) system 100 in a computer network 102. QA system 100may include knowledge manager 104, which comprises one or moreprocessors and one or more memories, and potentially any other computingdevice elements generally known in the art including buses, storagedevices, communication interfaces, and the like. Computer network 102may include other computing devices in communication with each other andwith other devices or components via one or more wired and/or wirelessdata communication links, where each communication link may comprise oneor more of wires, routers, switches, transmitters, receivers, or thelike. QA system 100 and network 102 may enable question/answer (QA)generation functionality for one or more content users. Otherembodiments may include QA system 100 interacting with components,systems, sub-systems, and/or devices other than those depicted herein.

QA system 100 may receive inputs from various sources. For example, QAsystem 100 may receive input from the network 102, a corpus ofelectronic documents 107 or other data, semantic data 108, and otherpossible sources of input. In one embodiment, some or all of the inputsto QA system 100 route through the network 102 and stored in knowledgebase 106. The various computing devices on the network 102 may includeaccess points for content creators and content users. Some of thecomputing devices may include devices for a database storing the corpusof data. The network 102 may include local network connections andremote connections in various embodiments, such that QA system 100 mayoperate in environments of any size, including local and global, e.g.,the Internet. Additionally, QA system 100 serves as a front-end systemthat can make available a variety of knowledge extracted from orrepresented in documents, network-accessible sources and/or structureddata sources. In this manner, some processes populate the knowledgemanager with the knowledge manager also including input interfaces toreceive knowledge requests and respond accordingly.

In one embodiment, a content creator creates content in a document 107for use as part of a corpus of data with QA system 100. The document 107may include any file, text, article, or source of data for use in QAsystem 100. Content users may access QA system 100 via a networkconnection or an Internet connection to the network 102, and may inputquestions to QA system 100, which QA system 100 answers according to thecontent in the corpus of data. As further described below, when aprocess evaluates a given section of a document for semantic content,the process can use a variety of conventions to query it from knowledgemanager 104. One convention is to send a well-formed question.

Semantic data 108 is content based on the relation between signifiers,such as words, phrases, signs, and symbols, and what they stand for,their denotation, or connotation. In other words, semantic data 108 iscontent that interprets an expression, such as by using Natural LanguageProcessing (NLP). In one embodiment, the process sends well-formedquestions (e.g., natural language questions, etc.) to QA system 100 andQA system 100 may interpret the question and provide a response thatincludes one or more answers to the question. In some embodiments, QAsystem 100 may provide a response to users in a ranked list of answers.

In some illustrative embodiments, QA system 100 may be the IBM Watson™QA system available from International Business Machines Corporation ofArmonk, N.Y., which is augmented with the mechanisms of the illustrativeembodiments described hereafter. The IBM Watson™ knowledge managersystem may receive an input question which it then parses to extract themajor features of the question, that in turn are then used to formulatequeries that are applied to the corpus of data. Based on the applicationof the queries to the corpus of data, a set of hypotheses, or candidateanswers to the input question, are generated by looking across thecorpus of data for portions of the corpus of data that have somepotential for containing a valuable response to the input question.

The IBM Watson™ QA system then performs deep analysis on the language ofthe input question and the language used in each of the portions of thecorpus of data found during the application of the queries using avariety of reasoning algorithms. There may be hundreds or even thousandsof reasoning algorithms applied, each of which performs differentanalysis, e.g., comparisons, and generates a score. For example, somereasoning algorithms may look at the matching of terms and synonymswithin the language of the input question and the found portions of thecorpus of data. Other reasoning algorithms may look at temporal orspatial features in the language, while others may evaluate the sourceof the portion of the corpus of data and evaluate its veracity.

The scores obtained from the various reasoning algorithms indicate theextent to which the potential response is inferred by the input questionbased on the specific area of focus of that reasoning algorithm. Eachresulting score is then weighted against a statistical model. Thestatistical model captures how well the reasoning algorithm performed atestablishing the inference between two similar passages for a particulardomain during the training period of the IBM Watson™ QA system. Thestatistical model may then be used to summarize a level of confidencethat the IBM Watson™ QA system has regarding the evidence that thepotential response, i.e. candidate answer, is inferred by the question.This process may be repeated for each of the candidate answers until theIBM Watson™ QA system identifies candidate answers that surface as beingsignificantly stronger than others and thus, generates a final answer,or ranked set of answers, for the input question. More information aboutthe IBM Watson™ QA system may be obtained, for example, from the IBMCorporation website, IBM Redbooks, and the like. For example,information about the IBM Watson™ QA system can be found in Yuan et al.,“Watson and Healthcare,” IBM developerWorks, 2011 and “The Era ofCognitive Systems: An Inside Look at IBM Watson and How it Works” by RobHigh, IBM Redbooks, 2012.

Types of information handling systems that can utilize QA system 100range from small handheld devices, such as handheld computer/mobiletelephone 110 to large mainframe systems, such as mainframe computer170. Examples of handheld computer 110 include personal digitalassistants (PDAs), personal entertainment devices, such as MP3 players,portable televisions, and compact disc players. Other examples ofinformation handling systems include pen, or tablet, computer 120,laptop, or notebook, computer 130, personal computer system 150, andserver 160. As shown, the various information handling systems can benetworked together using computer network 102. Types of computer network102 that can be used to interconnect the various information handlingsystems include Local Area Networks (LANs), Wireless Local Area Networks(WLANs), the Internet, the Public Switched Telephone Network (PSTN),other wireless networks, and any other network topology that can be usedto interconnect the information handling systems. Many of theinformation handling systems include nonvolatile data stores, such ashard drives and/or nonvolatile memory. Some of the information handlingsystems shown in FIG. 1 depicts separate nonvolatile data stores (server160 utilizes nonvolatile data store 165, and mainframe computer 170utilizes nonvolatile data store 175. The nonvolatile data store can be acomponent that is external to the various information handling systemsor can be internal to one of the information handling systems. Anillustrative example of an information handling system showing anexemplary processor and various components commonly accessed by theprocessor is shown in FIG. 2.

FIG. 2 illustrates information handling system 200, more particularly, aprocessor and common components, which is a simplified example of acomputer system capable of performing the computing operations describedherein. Information handling system 200 includes one or more processors210 coupled to processor interface bus 212. Processor interface bus 212connects processors 210 to Northbridge 215, which is also known as theMemory Controller Hub (MCH). Northbridge 215 connects to system memory220 and provides a means for processor(s) 210 to access the systemmemory. Graphics controller 225 also connects to Northbridge 215. In oneembodiment, PCI Express bus 218 connects Northbridge 215 to graphicscontroller 225. Graphics controller 225 connects to display device 230,such as a computer monitor.

Northbridge 215 and Southbridge 235 connect to each other using bus 219.In one embodiment, the bus is a Direct Media Interface (DMI) bus thattransfers data at high speeds in each direction between Northbridge 215and Southbridge 235. In another embodiment, a Peripheral ComponentInterconnect (PCI) bus connects the Northbridge and the Southbridge.Southbridge 235, also known as the I/O Controller Hub (ICH) is a chipthat generally implements capabilities that operate at slower speedsthan the capabilities provided by the Northbridge. Southbridge 235typically provides various busses used to connect various components.These busses include, for example, PCI and PCI Express busses, an ISAbus, a System Management Bus (SMBus or SMB), and/or a Low Pin Count(LPC) bus. The LPC bus often connects low-bandwidth devices, such asboot ROM 296 and “legacy” I/O devices (using a “super I/O” chip). The“legacy” I/O devices (298) can include, for example, serial and parallelports, keyboard, mouse, and/or a floppy disk controller. The LPC busalso connects Southbridge 235 to Trusted Platform Module (TPM) 295.Other components often included in Southbridge 235 include a DirectMemory Access (DMA) controller, a Programmable Interrupt Controller(PIC), and a storage device controller, which connects Southbridge 235to nonvolatile storage device 285, such as a hard disk drive, using bus284.

ExpressCard 255 is a slot that connects hot-pluggable devices to theinformation handling system. ExpressCard 255 supports both PCI Expressand USB connectivity as it connects to Southbridge 235 using both theUniversal Serial Bus (USB) the PCI Express bus. Southbridge 235 includesUSB Controller 240 that provides USB connectivity to devices thatconnect to the USB. These devices include webcam (camera) 250, infrared(IR) receiver 248, keyboard and trackpad 244, and Bluetooth device 246,which provides for wireless personal area networks (PANs). USBController 240 also provides USB connectivity to other miscellaneous USBconnected devices 242, such as a mouse, removable nonvolatile storagedevice 245, modems, network cards, ISDN connectors, fax, printers, USBhubs, and many other types of USB connected devices. While removablenonvolatile storage device 245 is shown as a USB-connected device,removable nonvolatile storage device 245 could be connected using adifferent interface, such as a Firewire interface, etcetera.

Wireless Local Area Network (LAN) device 275 connects to Southbridge 235via the PCI or PCI Express bus 272. LAN device 275 typically implementsone of the IEEE .802.11 standards of over-the-air modulation techniquesthat all use the same protocol to wireless communicate betweeninformation handling system 200 and another computer system or device.Optical storage device 290 connects to Southbridge 235 using Serial ATA(SATA) bus 288. Serial ATA adapters and devices communicate over ahigh-speed serial link. The Serial ATA bus also connects Southbridge 235to other forms of storage devices, such as hard disk drives. Audiocircuitry 260, such as a sound card, connects to Southbridge 235 via bus258. Audio circuitry 260 also provides functionality such as audioline-in and optical digital audio in port 262, optical digital outputand headphone jack 264, internal speakers 266, and internal microphone268. Ethernet controller 270 connects to Southbridge 235 using a bus,such as the PCI or PCI Express bus. Ethernet controller 270 connectsinformation handling system 200 to a computer network, such as a LocalArea Network (LAN), the Internet, and other public and private computernetworks.

While FIG. 2 shows one information handling system, an informationhandling system may take many forms, some of which are shown in FIG. 1.For example, an information handling system may take the form of adesktop, server, portable, laptop, notebook, or other form factorcomputer or data processing system. In addition, an information handlingsystem may take other form factors such as a personal digital assistant(PDA), a gaming device, ATM machine, a portable telephone device, acommunication device or other devices that include a processor andmemory.

FIGS. 3-6 depict an approach that uses a question answering (QA) systemto analyze software code based on learned programming construct patternsand natural language processing (NLP) similarities to complianceregulations. Compliance requirements are affecting an increasing numberof business processes. Many specialized processes are being designedsolely to meet industry specific regulations. As various complianceinitiatives become more intertwined from regulatory and organizationalperspectives, the use of multiple and disparate compliance solutions canlead to duplicate, and often contradictory, processes and documentation.Such environments do not provide clear visibility into organizations'risk and compliance profiles. They also reduce efficiency, and escalatethe cost of compliance.

Using the approach provided herein, software code is ingested into theQA system for a particular domain, such as software dealing with healthcare and patient records. In addition, regulations, such as laws,policies, and the like, promulgated by a government regulatory body orother compliance organization, are also ingested into the QA system.With the base of knowledge ingested into the QA system, software codebeing developed for the domain, such as a new or improvedpatient-management system for a hospital, is analyzed based upon theingested base of knowledge including the previously ingested softwarecode for the domain as well as the previously ingested softwarecompliance regulations. During analysis, NLS questions are formulatedbased on the various constructs found in the software code that is beinganalyzed. Using the patient software example, a construct such asroutine named “Retrieve_Patient_Record” would be selected and a NLSquestion formulated such as “Is the ‘Retrieve_Patient_Record’ routinesubject to any health care regulations?” This question is submitted tothe QA system that has a knowledge base of other health care softwareprograms and the health care regulations that were previously ingested.The QA system responds with an answer and a confidence level.

For example, the above-question may receive an answer that the routineis subject to a particular health care regulation with a confidencescore of 95 out of a possible 100, indicating a high confidence that thesoftware routine is subject to the cited regulation. The QA system isable to provide the regulation and a high confidence value when othersoftware previously ingested programs have routines with the same orsimilar names that were noted as being subject to the cited regulation.If other software programs do not have similar routine names, then theQA system can parse the question into component parts with the resultbeing that the routine deals with “patient names” and can also obtain ahigh confidence value by comparing the words and phrases to words andphrases found in the compliance regulations. In this case, the QA systemwould identify the cited regulation based on the ingested complianceregulations. Using a combination of both the previously ingestedsoftware code and the ingested software compliance regulations furtherbolster the QA system's confidence level that the posed question issubject to the cited regulation.

In one embodiment, multiple answers can be returned by the QA systemwith each answer having its own confidence level. Using the example fromabove, the QA system may find a first regulation dealing with thehandling of patient names and calculate a confidence value of 95/100, asecond regulation dealing with patient confidentiality and calculate aconfidence value of 88/100, and a third regulation dealing withinter-hospital communications and assign a lower confidence value of35/100. A threshold can be applied so that candidate answers with lowerscores are filtered out. In this case, if a threshold value of 75 isestablished then the first and second regulations would be noted aslikely applying to the selected routine dealing with retrieving patientrecords, and the third regulation would be filtered out as it isunlikely that the routine, with the given data, deals withinter-hospital communication. Of course, other variables and programmingconstructs in the routine may increase or decrease the confidence valuepertaining to each of the regulations and may further result in theinclusion of other compliance regulations.

FIG. 3 is an exemplary diagram showing processes and data storesutilized to search software source code based on learned programmingconstruct patterns and natural language processing (NLP) similarities.Question answering (QA) system 100 includes knowledge base 106, alsoreferred to as a “corpus” that is used by QA Engine 104 to answersubmitted questions.

The domain that is being addressed, such as health care, often has oneor more regulatory organizations, such as the FDA, that promulgatesoftware compliance regulations 320. Software developed for the domain(e.g., health care, etc.) is subject to these software complianceregulations. For example, certain documentation may be required whensoftware being developed by the software developer performs certaintasks. In the health care industry, certain documentation is requiredwhen software performs certain tasks related to patient identifies, suchas names, identification numbers, and the like. In the case of healthcare, such regulations are often enacted to protect patients' identifyand their privacy, such as ailments patients have experienced ortreatments that the patients have received. Process 325 ingests theregulations promulgated by the regulatory organization(s). Afteringestion, the compliance regulations are depicted as data store 330which is part of the QA system's corpus (knowledge base 106).

In many industries, such as health care, many software programs havealready been written that were previously made to comply with thesoftware compliance regulations. Archive 340 depicts a body of sourcecode previously written, and documented, that performs tasks andfunctions in the regulated industry. In the health care field, suchtasks and functions would include handling of patient records and otherhealth care related activities. Predefined process 350 ingests archive340 in order to build a domain-specific base of source code knowledge(see FIG. 4 and corresponding text for processing details). Afteringestion, the base of knowledge derived from the domain-specific sourcecode are depicted as data store 360 which is part of the QA system'scorpus (knowledge base 106). At this point, QA system 100 has beenprovided with domain-specific software compliance regulations (datastore 330) as well as a base of source code knowledge that has alreadybeen written for the domain (data store 360).

QA system 100 is now ready to answer questions pertaining to newsoftware programs being written for the domain. Predefined process 370analyzes new source code file 380 (see FIG. 5 and corresponding text forprocessing details). As shown in greater detail in FIG. 5, predefinedprocess 370 analyzes constructs included in source code file 380 andposes natural language questions to QA system 100 with the questionsfocused on whether various constructs and relationships (code sections)found in new source code file 380 are domain-specific (e.g., directed atthe health care domain, etc.) and whether such code sections are subjectto the software compliance regulations 330 previously ingested into theQA system's knowledge base 106. Armed with the regulations and thesource code archive, the QA system is able to respond with an answer asto whether the code section is domain-specific and whether such codesection is further subject to the software compliance regulations.Regulatory documentation 390 is output from predefined process 370providing details as to the code sections in the new source code thatare subject to the software compliance regulations. In one embodiment,regulatory documentation 390 includes specific citations, or references,to particular regulations. For example, in the health care domain, asoftware routine that retrieves a patient record would likely be subjectto one or more regulations promulgated by the FDA.

FIG. 4 is an exemplary flowchart showing steps performed to build adomain specific base of source code knowledge. FIG. 4 processingcommences at 400 and shows the steps taken by a process that performs aroutine that builds a domain-specific base of source code knowledge andingests the domain-specific knowledge to a corpus, or knowledge base,utilized by a question answering (QA) system. At step 405, the processselects the first source code file (e.g., program, etc.) from sourcecode archive 340. The selected source code and any metadata pertainingto the selected source code are stored in memory area 410. At step 415,the process selects the first block of code from the selected sourcecode. The selected block, also referred to as a “code section,” iswritten to memory area 420.

At step 425, the process classifies the selected block based on theoperation(s) performed by the block. For example, the selected blockcould be a conditional assignment, a manipulation routine, a transformerfunction, a routing function, and the like. The classification of theselected code section is written to memory area 420. In one embodiment,the following process is used to classify code:

-   -   1) Use prior art to classify all blocks/methods;    -   2) Blocks are classified:        -   a) as conditional assignments;        -   b) manipulation (bunch of sets/assignment on the same            object, no relationships);        -   c) transformer (reading values from one object, setting            (assignment) the value on another object); and        -   d) routing (reading values from one object, calling a            separate function/method based on condition).    -   3) Based on classification determine the object types and        whether any of them are in the medical domain by lexical        classification or manual annotation, or NLP parsing of comments;    -   4) Determine the object types in the code and their        relationships (affects, conditionally determines, routes to);    -   5) Match the entity relationships to corpora for the domain:        -   a) If they match assign a weight based on the type of block            and the relationship match;        -   b) Assign weight based on the property type match and the            classification types (assignment has similar or same            property in code and corpora); and        -   c) If they do not match assign a lower weight.    -   6) Based on the weighting and the object types match in the        corpora determine whether it should be deemed within the        requirement (FDA medical algorithms and how much); and    -   7) Show blocks of code identified as potential FDA Medical        algorithm with code reasoning based on classification and match        with evidence to corpora statements and annotations (tuple,        relationships) from corpora.

For example, in a medical context, a medical term, such as “anemia”might be found in the code, such as a programming statement like:

“public AdverseEvent gradeAnemia(Patient p, List<LabReport>labs { . . .”

Here, the term “anemia,” a medically relevant term, is found in the codeand any software compliance guidelines regarding such term would befound and processed accordingly.

At step 430, the process identifies the code section as being eitherdomain-specific or general purpose. The identification of the codesection is also written to memory area 420. In one embodiment, theselected code section is searched for keywords pertaining to the domain.If any such keywords are found, then the block is identified asdomain-specific, otherwise the block is identified as a general purposecode section. In a further embodiment, non-program language terms (e.g.,variables, function names, etc.) are compared to such non-programlanguage terms found in previously ingested source code files.Furthermore, in this embodiment, the QA system can be utilized to asknatural language questions such as “is the term ‘patient_name’ domainspecific?” with the QA system answering the question based upon theextent of the knowledge base of already-ingested source code files.

At step 435, the process selects the first program construct in theselected code section (e.g., variable, class, etc.). The selectedprogram construct is stored in memory area 440. At step 445, the processidentifies the selected construct as either being domain-specific orgeneral purpose with the identification being performed in a similarfashion as the identification of the code section itself (e.g.,utilizing keywords, comparing such constructs to previously ingestedconstructs from other source code files, etc.). The identification ofthe construct as being either domain-specific or general purpose is alsostored in memory area 440. The process determines as to whether thereare more program constructs in the selected code section to process(decision 450). If there are more program constructs in the selectedcode section to process, then decision 450 branches to the ‘yes’ branchwhich loops back to select and process the next program construct fromthe selected code section. This looping continues until there are nomore program constructs in the selected code section to process, atwhich point decision 450 branches to the ‘no’ branch for furtherprocessing.

At step 455, the process maps relationships between the selected codesection and other code sections. For example, the selected code sectionmay call or reference another code section or the selected code sectionmay be a function or procedure that is called or referenced by othercode sections. Such relationship data between code sections is stored inmemory area 460.

The process determines as to whether there more additional code sectionsin the selected source code file to process (decision 465). If there aremore additional code sections in the selected source code file toprocess, then decision 465 branches to the ‘yes’ branch which loops backto select and process the next code section as described above. Thislooping continues until there are no more code sections in the selectedsource code file to process, at which point decision 465 branches to the‘no’ branch and processing continues.

At step 470, the process ingests the source code from memory area 410,the code section classification data from memory area 420, the programconstruct data from memory area 440, and the relationship data frommemory area 440 into the QA system's corpus, or knowledge base, 106. Theprocess then determines as to whether there are more source code filesin archive 340 to process and ingest as described above (decision 475).If there are more source code files to process and ingest, then decision475 branches to the ‘yes’ branch which loops back to select and processthe next domain-specific source code file. This looping continues untilthere are no more source code files to process, at which point decision475 branches to the ‘no’ branch at which point processing ends at 495.

FIG. 5 is an exemplary flowchart that performs steps to comply withvarious regulations related to software that is being constructed. FIG.5 processing commences at 500 and shows the steps taken by a processthat performs a routine that analyzes a new source code file beingdeveloped for a domain and identifies regulations that apply to thesource code file.

At step 505, the process formulates a question pertaining to the newsource code file as being domain specific and whether the new sourcecode file is subject to domain specific regulations. At predefinedprocess 510, the process performs the Process Formulated Question by QASystem Routine (see FIG. 6 and corresponding text for processingdetails).

At step 515, the process selects the first code section from new sourcecode file 380. At step 520, the process classifies the selected codesection similar to the classification step 425 shown in FIG. 4 (e.g.,conditional assignments, manipulation, transformer, routing, etc.). Atstep 525, the process formulates a question pertaining to the selectedcode section and the code section classification as being domainspecific and whether the code section is subject to domain specificregulations. At predefined process 530, the process again performs theProcess Formulated Question by QA System Routine (see FIG. 6 andcorresponding text for processing details), this time processing thequestion formulated in step 525.

At step 535, the process selects the first programming construct fromthe selected code section (e.g., variable, class, etc.). At step 540,the process formulates a question pertaining to the selected programmingconstruct being domain specific and whether the selected programconstruct is subject to domain specific regulations. At predefinedprocess 545, the process again performs the Process Formulated Questionby QA System Routine (see FIG. 6 and corresponding text for processingdetails), this time processing the question formulated in step 540.

The process determines as to whether there are more program constructsin the selected code section to process (decision 550). If there aremore program constructs in the selected code section to process, thendecision 550 branches to the ‘yes’ branch which loops back to select andprocess the next program construct from the selected code section. Thislooping continues until there are no more program constructs to process,at which point decision 550 branches to the ‘no’ branch for furtherprocessing.

At step 555, the process maps the relationships between the selectedcode section and other code sections or routines. For example, theselected code section may call or reference other code sections orroutines. In addition, the selected code section may be a routine orfunction that is called or referenced by other code sections. At step560, the process formulates question(s) pertaining to the mappedrelationships as being domain specific and whether such relationshipsare subject to domain specific regulations. At predefined process 565,the process again performs the Process Formulated Question by QA SystemRoutine (see FIG. 6 and corresponding text for processing details), thistime processing the question formulated in step 560.

The process determines as to whether there are more code sections in thenew source code file to process (decision 570). If there are more codesections in the new source code file to process, then decision 570branches to the ‘yes’ branch which loops back to select and process thenext code section as described above. This looping continues until thereare no more code sections to process, at which point decision 570branches to the ‘no’ branch and processing ends at 595.

FIG. 6 is an exemplary flowchart that processes formulated questionspertaining to code using a question/answering (QA) system. FIG. 6processing commences at 600 and shows the steps taken by a process thatperforms a routine that processes a formulated question using the QAsystem. At step 605, the process submits the formulated question to theQA System where it is processed by QA system pipeline 310.

QA system pipeline includes a number of processes that break thesubmitted question down in order to search the QA system's knowledgebase 106 for an answer to the submitted question. As shown in FIG. 5,the submitted questions are formulated in a natural language format,such as “is the term ‘patient_record’ a domain specific term?” and thelike depending on the aspect of the source code file that is beinganalyzed. At step 615, the QA system pipeline commences and firstperforms a question and topic analysis. Next, at step 620, the QA systempipeline performs a question decomposition process. At step 625, the QAsystem pipeline next performs a primary search for the submittedquestion using knowledge base 106. At step 630, the QA system pipelinethen generates candidate answers to the submitted question. At step 635,the QA system pipeline scores the candidate answers. At step 640, the QAsystem pipeline retrieves supporting evidence from the knowledge base(corpus). At step 645, the QA system pipeline performs a deep evidencescoring process using the knowledge base. At step 650, the QA systempipeline performs a final merging and ranking resulting in one or morecandidate answers as well as a confidence value pertaining to thevarious candidate answers.

Candidate answers with low confidence values are filtered out at thispoint in the process. The answers and their respective confidence valuesare stored in data store 360. In addition, references to specificregulations are written to data store 355 along with the respective codesection(s) to which the regulations apply.

At step 665, the process receives the response from the QA system. Theresponse includes answers, confidence values, and supporting evidence aswell as the cited regulations and the code sections, constructs, orrelationships to which the regulations apply. The process determines asto whether the answer's confidence value is greater than an establishedthreshold (decision 670). If the answer's confidence value is greaterthan an established threshold, then decision 670 branches to the ‘yes’branch whereupon, at step 675, the step writes the code section and/orconstruct and the domain-specific regulation to required regulatorydocumentation 390 with the domain-specific regulation being theregulation, or regulations, that apply to the code section, constructs,or relationships. On the other hand, if the answer's confidence value isless than the established threshold or the answer indicates that thecode section, construct, or relationship are general purpose and notdomain specific, then decision 670 branches to the ‘no’ branch bypassingstep 675. Processing then returns to the calling routine (see FIG. 5) at695.

While particular embodiments of the present disclosure have been shownand described, it will be obvious to those skilled in the art that,based upon the teachings herein, that changes and modifications may bemade without departing from this disclosure and its broader aspects.Therefore, the appended claims are to encompass within their scope allsuch changes and modifications as are within the true spirit and scopeof this disclosure. Furthermore, it is to be understood that thedisclosure is solely defined by the appended claims. It will beunderstood by those with skill in the art that if a specific number ofan introduced claim element is intended, such intent will be explicitlyrecited in the claim, and in the absence of such recitation no suchlimitation is present. For non-limiting example, as an aid tounderstanding, the following appended claims contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimelements. However, the use of such phrases should not be construed toimply that the introduction of a claim element by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim element to disclosures containing only one suchelement, even when the same claim includes the introductory phrases “oneor more” or “at least one” and indefinite articles such as “a” or “an”;the same holds true for the use in the claims of definite articles.

The invention claimed is:
 1. An information handling system comprising:one or more processors; one or more data stores accessible by at leastone of the processors; a memory coupled to at least one of theprocessors; and a set of computer program instructions stored in thememory and executed by at least one of the processors in order toperform actions of: building a domain-specific knowledge base of adomain by ingesting a plurality of source code files into thedomain-specific knowledge base utilized by a question/answering (QA)system, wherein the ingesting further comprises: ingesting a set ofsoftware compliance regulations corresponding to the domain into thedomain-specific knowledge base; selecting one of the plurality of sourcecode files that includes a plurality of source code sections;classifying one of the plurality of source code sections as adomain-specific source code section; and classifying a construct in thedomain-specific source code section as a domain-specific construct;retrieving a new source code file that comprises a plurality of newsource code sections, wherein a selected one of the plurality of newsource code sections includes a new construct; generating a naturallanguage question based on the new construct; and processing, by the QAsystem, the natural language question using the domain-specificknowledge base, wherein the processing further comprises: matching thenew construct to the domain-specific construct; determining, in responseto the matching, that the selected source code section is subject to theingested set of software compliance regulations; and generating ananswer, in response the determining, that indicates the new source codesection is subject to the set of software compliance regulations.
 2. Theinformation handling system of claim 1 wherein the actions furthercomprise: identifying one or more domain-specific relationships betweenthe plurality of new code sections of the new source code file; andusing the QA system, analyzing compliance of the new source code file byfurther determining whether the identified one or more domain-specificrelationships are subject to the ingested set of software complianceregulations.
 3. The information handling system of claim 1 furthercomprising: formulating a different natural language question pertainingto the new source code file being domain specific and subject to theingested set of software compliance regulations; submitting thedifferent natural language question to the QA system; and receiving aresponse from the QA system that indicates whether the new source codefile is subject to the ingested set of software compliance regulations.4. The information handling system of claim 1 wherein the actionsfurther comprise: receiving, from the QA system, a confidence valuecorresponding to the answer; and in response to the confidence valueexceeding a threshold, generating a report that indicates the new sourcecode section is subject to the ingested set of software complianceregulations.
 5. The information handling system of claim 4 wherein theactions further comprise: including the set of software complianceregulations in the report.
 6. A computer program product stored in acomputer readable storage medium, comprising computer program code that,when executed by an information handling system, causes the informationhandling system to perform actions comprising: building adomain-specific knowledge base of a domain by ingesting a plurality ofsource code files into the domain-specific knowledge base utilized by aquestion/answering (QA) system, wherein the ingesting further comprises:ingesting a set of software compliance regulations corresponding to thedomain into the domain-specific knowledge base; selecting one of theplurality of source code files that includes a plurality of source codesections; classifying one of the plurality of source code sections as adomain-specific source code section; and classifying a construct in thedomain-specific source code section as a domain-specific construct;retrieving a new source code file that comprises a plurality of newsource code sections, wherein a selected one of the plurality of newsource code sections includes a new construct; generating a naturallanguage question based on the new construct; and processing, by the QAsystem, the natural language question using the domain-specificknowledge base, wherein the processing further comprises: matching thenew construct to the domain-specific construct; determining, in responseto the matching, that the selected source code section is subject to theingested set of software compliance regulations; and generating ananswer, in response the determining, that indicates the new source codesection is subject to the set of software compliance regulations.
 7. Thecomputer program product of claim 6 wherein the actions furthercomprise: identifying one or more domain-specific relationships betweenthe plurality of new code sections of the new source code file; andusing the QA system, analyzing compliance of the new source code file byfurther determining whether the identified one or more domain-specificrelationships are subject to the ingested set of software complianceregulations.
 8. The computer program product of claim 6 furthercomprising: formulating a different natural language question pertainingto the new source code file being domain specific and subject to theingested set of software compliance regulations; submitting thedifferent natural language question to the QA system; and receiving aresponse from the QA system that indicates whether the new source codefile is subject to the ingested set of software compliance regulations.9. The computer program product of claim 6 wherein the actions furthercomprise: receiving, from the QA system, a confidence valuecorresponding to the answer; and in response to the confidence valueexceeding a threshold, generating a report that indicates the new sourcecode section is subject to the ingested set of software complianceregulations; and including the set of software compliance regulations inthe report.